System and method for scalable and redundant COPS message routing in an IP multimedia subsystem

ABSTRACT

An Internet Protocol (IP) multimedia subsystem for use in a telecommunication network. The IP multimedia subsystem comprises: 1) an IP switch for receiving Common Open Policy Service (COPS) protocol messages from an external IP network; and 2) a plurality of call application nodes capable of executing a plurality of Policy Decision Function (PDF) application groups. The IP switch distributes the COPS messages to the plurality of call application nodes according to a load-sharing algorithm.

CROSS-REFERENCE TO RELATED APPLICATION

The present invention is related to that disclosed in U.S. patentapplication Ser. No. 10/038,878, filed on Dec. 31, 2001 and entitled“System and Method for Distributed Call Processing Using Load-SharingGroups.” patent application Ser. No. 10/038,878 is assigned to theassignee of the present application. The subject matter disclosed inpatent application Ser. No. 10/038,878 is hereby incorporated byreference into the present disclosure as if fully set forth herein. Thepresent application is a continuation-in-part (CIP) of patentapplication Ser. No. 10/038,878 and hereby claims priority under 35U.S.C. §120 to the filing date of patent application Ser. No.10/038,878.

TECHNICAL FIELD OF THE INVENTION

present invention generally relates to telecommunication systems and,more specifically, to a scalable and redundant IP multimedia subsystem(IMS) for performing COPS message routing.

BACKGROUND OF THE INVENTION

The 3GPP standard describes an Internet Protocol (IP) multimediasubsystem (IMS) that comprises the core network (CN) devices thatprovide IP multimedia services, including audio, video, text, chat andthe like, and combinations thereof, delivered over the Internet and/orthe public switched telephone network. Conventional IP multimediasubsystems generally comprise an IP switch and a single server. Asnetwork loading increases, more processors may be added to the server tocope with the increased throughput requirements.

However, at some point, adding more processors becomes inadequate due tolimitations in the capacity of the server. For example, the bandwidth ofthe server may limit the usefulness of this approach. In a number ofsystems, it is not possible to add more processors. At that point,faster and more powerful processors must be added, which also is alimited approach.

Also, the conventional architecture of an IP switch and a single serveris limited by a single point of failure. If the server fails, then allservice is lost. The prior art IP multimedia subsystems use the IPswitch to detect when a node has failed. The conventional IP multimediasubsystems do not detect when a server has failed.

Therefore, there is a need in the art for an improved IP multimediasubsystem that is capable of providing scalable service to cope withincreased traffic requirements. In particular, there is a need for an IPmultimedia subsystem that does not contain a single point of failure.

SUMMARY OF THE INVENTION

The present invention provides for the easy expansion of the number ofnodes in an IP multimedia subsystem (IMS) in order to handle theexpected network traffic. The IMS is more fault-tolerant because for anyfailure by a node, application server, or application level gateway, abackup device takes over to continue to provide service.

To address the above-discussed deficiencies of the prior art, it is aprimary object of the present invention to provide an Internet Protocol(IP) multimedia subsystem for use in a telecommunication network.According to an advantageous embodiment of the present invention, the IPmultimedia subsystem comprises: 1) an IP switch capable of receivingCommon Open Policy Service (COPS) messages from an external gateway GPRSsupport node; and 2) a plurality of call application nodes capable ofexecuting a plurality of Policy Decision Function (PDF) applicationgroups. The IP switch distributes the COPS messages to the plurality ofcall application nodes according to a load sharing algorithm.

According to one embodiment of the present invention, a first one of theplurality of PDF application groups is executed on a first one of theplurality of call application nodes and is associated with a similarsecond one of the plurality of PDF application groups executed on asecond one of the plurality of call application nodes separate from thefirst call application node.

According to another embodiment of the present invention, the first andsecond PDF application groups form a first load-sharing group serviceapplication.

According to still another embodiment of the present invention, thefirst PDF application group comprises a first primary applicationexecuted on the first call application node and a first backupapplication associated with the first primary application.

According to yet another embodiment of the present invention, the firstbackup application resides on a call application node other than thefirst call application node.

According to a further embodiment of the present invention, the IPmultimedia subsystem further comprises a plurality of front-end nodescapable of executing a plurality of application level gateway (ALG)application groups, wherein the IP switch distributes the COPS messagesto the plurality of front-end nodes for subsequent distribution to theplurality of call application nodes.

According to a still further embodiment of the present invention, afirst of the plurality of ALG application groups comprises a firstprimary ALG application executed on the first call application node anda first backup ALG application associated with the first primary ALGapplication.

According to a yet further embodiment of the present invention, thefirst backup ALG application resides on a call application node otherthan the first call application node.

Before undertaking the DETAILED DESCRIPTION OF THE INVENTION below, itmay be advantageous to set forth definitions of certain words andphrases used throughout this patent document: the terms “include” and“comprise,” as well as derivatives thereof, mean inclusion withoutlimitation; the term “or,” is inclusive, meaning and/or; the phrases“associated with” and “associated therewith,” as well as derivativesthereof, may mean to include, be included within, interconnect with,contain, be contained within, connect to or with, couple to or with, becommunicable with, cooperate with, interleave, juxtapose, be proximateto, be bound to or with, have, have a property of, or the like; and theterm “controller” means any device, system or part thereof that controlsat least one operation, such a device may be implemented in hardware,firmware or software, or some combination of at least two of the same.It should be noted that the functionality associated with any particularcontroller may be centralized or distributed, whether locally orremotely. Definitions for certain words and phrases are providedthroughout this patent document, those of ordinary skill in the artshould understand that in many, if not most instances, such definitionsapply to prior, as well as future uses of such defined words andphrases.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and itsadvantages, reference is now made to the following description taken inconjunction with the accompanying drawings, in which like referencenumerals represent like parts:

FIG. 1 illustrates a telecommunication network comprising an IPmultimedia subsystem (IMS) according to the principles of the presentinvention;

FIG. 2 illustrates the IP multimedia subsystem (IMS) in greater detailaccording to an exemplary embodiment of the present invention; and

FIG. 3 is a flow diagram illustrating the operation of the IP multimediasubsystem (IMS) according to an exemplary embodiment of the presentinvention.

DETAILED DESCRIPTION OF THE INVENTION

FIGS. 1 through 3, discussed below, and the various embodiments used todescribe the principles of the present invention in this patent documentare by way of illustration only and should not be construed in any wayto limit the scope of the invention. Those skilled in the art willunderstand that the principles of the present invention may beimplemented in any suitably arranged IP multimedia subsystem.

FIG. 1 illustrates telecommunication network 100, which comprises IPmultimedia subsystem (IMS) 110 according to the principles of thepresent invention. Telecommunication network 100 comprises IP multimediasubsystem (IMS) 110, gateway GPRS support node (GGSN) 111, gateway GPRSsupport node (GGSN) 112, gateway GPRS support node (GGSN) 113, andgateway GPRS support node (GGSN) 114. Gateway GPRS support nodes 111-114communicate with IMS 110 according to the General Packet Radio Service(GPRS) protocol via a public or a private Internet Protocol (IP)network, such Internet 120. Alternatively, gateway GPRS support nodes111-114 may communicate with IMS 110 via the public switched telephonenetwork (PSTN).

IP multimedia subsystem (IMS) 110 provides IP multimedia servicesincluding, for example, streaming audio, streaming video, textmessaging, chat, and the like, to end-user devices 111-114 over Internet120. IMS 110 comprises Internet protocol (IP) switch 130, front-end (orfirewall) server group 140, and application server group 150. Front-endserver group 140 comprises a plurality of front-end (or firewall) nodes,including front-end node (FN) 141 and front-end (FN) node 142. Applicantserver group 150 comprises a plurality of call application nodes,including call application node (CAN) 151, call application node (CAN)152, and call application node (CAN) 153.

Each of front-end nodes 141 and 142 comprises an application levelgateway (ALG) application, such as ALG application 143 in FN 141. Eachone of call application nodes 151-153 contains control applications (orprograms) for providing a plurality of call control functions orservices, including, for example, policy decision function (PDF)applications, various types of application server (AS) applications,IMS-service switching functions (IM-SSF) applications, proxy callsession control function (P-CSCF) applications, serving call sessioncontrol function (S-CSCF) applications, interrogator call sessioncontrol function (I-CSCF) applications, and other control software.

The IMS standard specifies the use of the Common Open Policy Service(COPS) protocol between gateway GPRS support nodes in external networks(e.g., GGSN 111-GGSN 114) and Policy Decision Function (PDF)applications internal to IMS 100. The PDF applications are a logicalentity of the P-CSCF application(s). A PDF application functions as aPolicy Decision Point for the service-based local policy control. ThePDF application makes policy decisions based on session information andmedia-related information obtained from the P-CSCF application via theGq interface (Diameter). The PDF application exchanges the decisioninformation with the external GGSN via the Go interface (COPS andCOPS-PR).

The expected COPS network traffic for the PDF applications varies fromsystem to system. An IP multimedia subsystem according to the principlesof the present invention provides easily scalability for handlingvarying traffic loads. The exemplary IMS 110 also is secure, faulttolerant, and highly available.

In IMS 110, the COPS stack is over TCP. The COPS protocol employs aclient-server model where a target gateway GPRS support node (GGSN)sends request messages, update messages, and delete messages to the PDFapplications in call application nodes 151-153 in IMS 110 and the PDFapplications return decisions back to the target GGSN. Each gateway GPRSsupport node is identified by a unique GGSN ID. A gateway GPRS supportnode makes a connection to a PDF application that persists over the lifeof multiple transactions. Each transaction is a set of messages betweenthe GGSN and the PDF application. Each transaction is identified by aClient Handle that is defined by the GGSN.

When a GGSN initiates a TCP connection, IP switch 130 load-shares theconnection to one of a pool of available front-end nodes. The ALGapplication within the front-end node detects a connection request andaccepts the connection from the GGSN. The ALG application thenmulticasts to all PDF application in IMS 110 the ALG group identity thathas the interface for the GGSN ID. For each set of transactionsinitiated by the GGSN, the ALG application load-shares the transactionto a specific PDF application. The ALG application keeps an associationbetween the Transaction ID and the PDF Group ID that services thetransaction. For any transaction messages from the GGSN, the ALGapplication looks up the PDF Group ID associated with the Transaction IDand then sends the message to the PDF application. The PDF applicationsends messages targeted to a specific GGSN by sending to the ALG groupthat is handling that GGSN.

External devices, including gateway GPRS support nodes, may sendmessages that are targeted to a particular type of service. Each type ofservice is given an IP address provided by IP switch 130. As an example,there is a first IP address for the P-CSCF applications, a second IPaddress for the I-CSCF applications, a third IP address for the S-CSCFapplications, and additional addresses for each type of AS applicationin IMS 110. IP switch 130 load-shares each received message to group 140of front-end nodes.

The applications are organized into load-sharing groups by applicationtype, such as P-CSCF, I-CSCF, S-CSCF, and one for each different type ofAS. The mechanism for forming and using load-sharing groups is disclosedin U.S. patent application Ser. No. 10/038,878, filed on Dec. 31, 2001and entitled “System and Method for Distributed Call Processing UsingLoad-Sharing Groups.” The disclosure and teachings of U.S. patentapplication Ser. No. 10/038,878 are hereby incorporated by referenceinto the present application as if fully set forth herein.

FIG. 2 illustrates IP multimedia subsystem (IMS) 210 in greater detailaccording to an exemplary embodiment of the present invention. In FIG.3, IMS 210 implements two front-end nodes (i.e., FN1 and FN2) and fivecall application nodes (i.e., CAN1, CAN2, CAN3, CAN4, and CAN5). Theservices or functions provided by CAN1-CAN5 and FN1 and FN2 areimplemented as group services. Each load-sharing group consists of oneof more primary-backup groups, where each primary-backup group isimplemented as a primary (P) application and a backup (B) application.For example, in FIG. 2, an application server (AS) load sharing group isimplemented as three primary-backup groups, AS1, AS2 and AS3. AS1comprises a primary application, AS1(P), and a backup application,AS1(B). AS2 comprises a primary application, AS2(P), and a backupapplication, AS2(B). AS3 comprises a primary application, AS3(P), and abackup application, AS3(B).

The server applications AS1, AS2 and AS3 all perform the same function.The primary members AS1(P), AS2(P), and AS3(P) perform the actual work,while the backup members, AS1(B), AS2(B), AS3(B) remain available andare updated in the background in case of failure by the correspondingprimary group member. In FIG. 2, only one AS application is shown.However, if other application server (AS) applications are implemented,the AS applications A, B and C may be identified as AS-A, AS-B, andAS-C. Primary-backup groups associated with, for example, AS-A, may thenbe identified as AS-A1(P) and AS-A1(B), AS-A2(P) and AS-A2(B), AS-A3(P)and AS-A3(B), and so forth. For the sake of simplicity, the P-CSCF,I-CSCF, and S-CSCF applications are each illustrated as comprising onlyone primary-backup group. However, in alternate embodiments, each ofthese CSCF applications may comprise a plurality of primary-backupgroups.

A group service provides a framework for organizing a group ofdistributed software objects in a computing network. Each softwareobject provides a service. In addition, the group service frameworkprovides enhanced behavior for determining group membership, whatactions to take in the presence of faults, controlling unicast,multicast, and groupcast communications between members and clients forthe group, and the like. A group utilizes a policy to enhance thebehavior of the services provided by the group. Some of these policiesinclude primary/backup for high service availability and load-sharingalgorithms for distributing the loading of services within a network.

A client application establishes an interface to the load-sharing group.The client application may either load share a message to one of themembers of the load-sharing group or may send the message directly to aspecific member. Each primary-backup group is identified by a particulargroup identity. When a message is sent to a member that was selected bya load-sharing algorithm, this is referred to as “load-sharing” themessage. When the message is sent using a group identity, this isreferred to as “Group ID-based routing.”

Each service type has its own load sharing group. As an example, thereis a PDF load sharing group, a P-CSCF load sharing group, an I-CSCF loadsharing group, an S-CSCF load sharing group, and a load sharing groupfor each type of AS application. A load sharing group has one or moremembers. Each member is the primary element in a primary-backup groupand resides within some application that executes within a callapplication node. Applications may be added to or removed from aload-sharing group at any time—either through failure or configuration.As long as at least one member of the group is active, the correspondingservice will be being provided.

As in the case of the AS applications, the PDF applications areimplemented in a PDF load-sharing group (LSG) consisting of threeprimary-backup groups (PDF1, PDF2 and PDF3), where each primary-backupgroup is implemented as a primary (P) application and a backup (B)application. There are multiple numbers (i.e., 3 in FIG. 2) of theseprimary-backup groups and the exact number is scalable according to thenumber of processes and/or computing nodes that are used.

In order to be fault tolerant and to be highly available, the primaryand backup members of each group in a load-sharing group are stripedacross the available CAN nodes. As an example, if three CAN nodes areimplemented, the normal primary (P) for primary-backup Group 1 (PBG1) isin CAN1 and the backup (B) is in CAN2. The normal primary (P) for PBG2is in CAN2 and the backup (B) is in CAN3. The normal primary for PBG3(P) is in CAN3 and the backup (B) is in CAN1. By way of example, thethree primary-backup group members of the PDF load-sharing group arestriped across CAN1-CAN5.

The primary member is the service provider and equalizes the state ofthe primary with that of the backup. If the primary should fail, thebackup takes over and continues to provide service until the primary isreloaded and assumes the role of primary. Failover is transparent toclient users of the primary-backup group.

The ALG application located in each front-end node is also organizedinto a load-sharing group. In the example, the ALG load-sharing groupcomprises two primary-backup groups, namely ALG1 and ALG2. ALG1 and ALG2 perform the same function. Each one of ALG1 and ALG2 consists of aprimary member and a backup member. As before, the primary members,ALG1(P) and ALG2(P), and the backup members, ALG1(B) and ALG2(B), arestriped across the available number of front-end nodes, which may beadded to or removed at anytime transparent to the service that is beingprovided.

FIG. 3 is a flow diagram illustrating the operation of IP multimediasubsystem (IMS) 110 according to an exemplary embodiment of the presentinvention. It is assumed that five (5) call application nodes (i.e.,CAN1-CAN5) and two (2) front-end nodes (FN1 and FN2) are implemented.Initially, external gateway GPRS support node (GGSN) 111 makes a TCPconnection using the public PDF IP address provided by IP switch 130.Next, IP switch 130 load-shares the connection to one of the front-endnodes (process step 305).

By way of example, it is assumed that the ALG2(P) application in FN2accepts the connection. ALG2(P) receives a COPS Open message indicatingthat GGSN 111 made the connection. ALG2(P) multicasts to the PDF LSGthat the ALG2(P) in FN2 has the TCP connection to GGSN 111. This permitsany PDF to originate a transaction or a close to GGSN 111 (process step310).

GGSN 111 sends a Request message to ALG2(P) in FN2 (process step 3105).The Request message begins a transaction. ALG2(P) selects one of theavailable PDF applications using the PDF LSG and sends the Requestmessage to, for example, PDF1(P) in CAN1. ALG2(P) in FN2 records thefact that CAN1 is handling this particular transaction identified by theClient Handle in the Request message. Subsequent messages from GGSN 111for this Client Handle will be routed to the PDF1(P) in CAN1 (processstep 320).

When the transaction is ended, GGSN 111 sends a Delete Request Statemessage to ALG2(P) in FN2. ALG2(P) removes the association of the ClientHandle with PDF1(P) in CAN1 (process step 320). When GGSN 111 initiatesanother transaction, ALG2(P) may assign PDF2(P) in CAN2 to handle thetransaction, and so on. Each PDF application in CAN1-CAN5 knows where tosend the response, because the message delivered to the PDF applicationcontains the ALG2(P) Group ID. The PDF application routes the messageusing Group ID-based routing.

IP switch 130 is configured to provide an IP address for TCP for the PDFservice type. Gateway GPRS support nodes 111-114 send messages using theIP address for the PDF service type. Associated with the PDF servicetype IP address is a pool of IP addresses—one for each front-end node inthe system. IP switch 130 load-shares TCP connections to a member of theIP pool.

If a front-end node should fail, IP switch 130 stops sending messages tothat node. When the front-end node recovers, IP switch 130 againdistributes messages to that node. IP switch 130 determines when thenode fails by sending ping messages to the node or detecting adisconnection of the TDP interface. When a ping message is no longerreturned or a disconnect is detected, IP switch 130 assumes that thenode has failed.

ALG applications send messages to gateway GPS support nodes 111-114using the TCP connection. IP switch 130 routes the messages to thecorrect GGSN. IP switch 130 is configured to support both IPV6 and IPV4connections. NAT-PT is used to translate between IPV4 messages and IPV6messages for IPV4 networks. IP switch 130 also supports IPV6 tunnelingover IPV4 networks.

IP switch 130 is configured to have an IP address for the PDF servicetype. Front-end nodes may easily be added or removed by changing the PDFservice type pool in IP switch 130. This enhances the scalability of IMS110. IP switch 130 provides network address translation between the PDFservice type IP address and the internal FN pool address. This enhancesthe security of the system. IP switch 130 detects front-end nodefailures and routes messages to available nodes. This enhances the highavailability of the system.

IPV4 and IPV6 networks must be supported according to the 3GPP IMSrequirements. The FN Ethernet interface to IP switch 130 is configuredas an IPV6 socket. Call application nodes, such as CAN1-CAN5, are notrequired to be IPV6, but can be configured as such. By putting an IPV6interface in the front-end node, call application node servers do nothave to be responsible for address translation between IPV4 and IPV6addresses. The ALG applications perform a simple translation betweenIPV4 to IPV6 by adding the IPV6 prefix [::ffff:0:0].

Each front-end node is configured with a VIP (Virtual IP address), onefor the PDF service type. The VIP address is referred to as virtualbecause it migrates between two different nodes. For example, for oneP-CSCF service, one I-CSCF service, one S-CSCF service, and one AS, eachfront-end node would be configured with four VIP addresses. All of theP-CSCF VIP addresses (one for each FN) are configured into the P-CSCFpool in IP switch 130 for the P-CSCF service type. The same is true forthe other service types.

As shown in FIG. 2, each ALG application is a member of a primary-backupgroup. The primary members and backup members are striped across theavailable front-end nodes. For two front-end nodes, FN1 and FN2, theprimary for ALG1 is in FN1 and the backup for ALG1 is in FN2. Similarly,the primary for ALG2 is in FN2 and the backup for ALG2 is in FN1. Allprimary members join the ALG load-sharing group (LSG). The primary iscompletely stateless and no equalization with the backup occurs.Instead, the backup is used for service availability.

The primary for ALG1 (i.e., ALG1(P)) in FN1 adds the PDF VIP to thelocal Ethernet interface on initialization. ALG1(P) then sends aGratuitous ARP message to IP switch 130 announcing that the VIP addressis associated with the FN1 MAC address. A Gratuitous ARP message is anunsolicited message sent as an ARP Request message to IP switch 130. If,in the future, IP switch 130 sends an ARP Request message for the VIPaddress, ALG1(P) replies that the VIP is on the MAC address for FN1. IfALG1(P) fails, Group Services detects the failure and notifies ALG1(B)to become primary. The new primary, ALG1(B), in FN2 modifies the VIP/MACaddress association in FN1 and associates the VIP address with the MACaddress of FN2. The new primary in FN2 then sends a Gratuitous ARPmessage to IP switch 130 announcing the interface change. For anysubsequent queries by IP switch 130 for the VIP address, ALG1(B) in FN2provides the ARP Reply. This mechanism ensures that as long as one ALGapplication is running in IMS 110, COPS service access will always beavailable. This mechanism is called IP Takeover.

The ALG load-sharing group maintains a Group Service client interface tothe PDF load-sharing group. The ALG LSG has a listener socket interfacefor the PDF service type VIP. When a connection comes in from a GGSN,the ALG LSG accepts the message and receives the COPS Client Openmessage. When the ALG application receives a COPS message over the PDFVIP address, the ALG application uses the associated client interfacefor the PDF service type load-sharing group. The ALG application usesthe client interface to multicast a notification to all members of thePDF LSG that ALG is handling a particular GGSN. The ALG applicationload-shares each new transaction to a member of the PDF LSG and usesGroup ID-based routing to send transaction messages to a particular PDF.

Periodically, the GGSN (i.e., GGSN 111) sends a COPS Keep Alive messageto the PDF LSG. The ALG LSG load-shares the Keep Alive message to a PDFapplication. If the PDF application responds, the ALG applicationreturns the response back to the GGSN. If the PDF does not respond, theALG application continues to load-share the Keep Alive message untileither a PDF responds or the number of available PDF servers isexhausted. If no response has been received, the ALG application doesnot send a response to the GGSN.

An important aspect of the present invention is the use of GroupID-based routing for COPS messages. For new COPS transactions, the ALGLSG load-shares the Request message to a particular PDF. The ALG LSGassociates the Client Handle, which is the Transaction ID, with the PDFGroup ID. Thereafter, each COPS message from GGSN 111 that has the sameClient Handle is sent to the same PDF using Group ID-based routing. PDFapplications and call application nodes may be added, removed, or fail,but the ALG LSG continues to operate as long as there is at least onePDF server running. This feature permits the system to be linearlyscalable and highly available.

Although the present invention has been described with an exemplaryembodiment, various changes and modifications may be suggested to oneskilled in the art. It is intended that the present invention encompasssuch changes and modifications as fall within the scope of the appendedclaims.

1. For use in a telecommunication network, an Internet Protocol (IP)multimedia subsystem comprising: an IP switch capable of receivingCommon Open Policy Service (COPS) messages from an external gateway GPRSsupport node; and a plurality of call application nodes capable ofexecuting a plurality of Policy Decision Function (PDF) applicationgroups, wherein said IP switch distributes said COPS messages to saidplurality of call application nodes according to a load sharingalgorithm.
 2. The IP multimedia subsystem as set forth in claim 1,wherein a first one of said plurality of PDF application groups isexecuted on a first one of said plurality of call application nodes andis associated with a similar second one of said plurality of PDFapplication groups executed on a second one of said plurality of callapplication nodes separate from said first call application node.
 3. TheIP multimedia subsystem as set forth in claim 2, wherein said first andsecond PDF application groups form a first load-sharing group serviceapplication.
 4. The IP multimedia subsystem as set forth in claim 3,wherein said first PDF application group comprises a first primaryapplication executed on said first call application node and a firstbackup application associated with said first primary application. 5.The IP multimedia subsystem as set forth in claim 4, wherein said firstbackup application resides on a call application node other than saidfirst call application node.
 6. The IP multimedia subsystem as set forthin claim 5, further comprising a plurality of front-end nodes capable ofexecuting a plurality of application level gateway (ALG) applicationgroups, wherein said IP switch distributes said COPS messages to saidplurality of front-end nodes for subsequent distribution to saidplurality of call application nodes.
 7. The IP multimedia subsystem asset forth in claim 6, wherein a first of said plurality of ALGapplication groups comprises a first primary ALG application executed onsaid first call application node and a first backup ALG applicationassociated with said first primary ALG application.
 8. The IP multimediasubsystem as set forth in claim 7, wherein said first backup ALGapplication resides on a call application node other than said firstcall application node.
 9. A telecommunication network comprising: aplurality of gateway GPRS support nodes of communicating according tothe Common Open Policy Service (SIP) protocol; a Internet protocol (IP)network coupled to said plurality of gateway GPRS support nodes; and aInternet Protocol (IP) multimedia subsystem comprising: an IP switchcapable of receiving Common Open Policy Service (COPS) messages fromsaid plurality of gateway GPRS support nodes; and a plurality of callapplication nodes capable of executing a plurality of Policy DecisionFunction (PDF) application groups, wherein said IP switch distributessaid COPS messages to said plurality of call application nodes accordingto a load sharing algorithm.
 10. The telecommunication network as setforth in claim 9, wherein a first one of said plurality of PDFapplication groups is executed on a first one of said plurality of callapplication nodes and is associated with a similar second one of saidplurality of PDF application groups executed on a second one of saidplurality of call application nodes separate from said first callapplication node.
 11. The telecommunication network as set forth inclaim 10, wherein said first and second PDF application groups form afirst load-sharing group service application.
 12. The telecommunicationnetwork as set forth in claim 11, wherein said first PDF applicationgroup comprises a first primary application executed on said first callapplication node and a first backup application associated with saidfirst primary application.
 13. The telecommunication network as setforth in claim 12, wherein said first backup application resides on acall application node other than said first call application node. 14.The telecommunication network as set forth in claim 13, furthercomprising a plurality of front-end nodes capable of executing aplurality of application level gateway (ALG) application groups, whereinsaid IP switch distributes said COPS messages to said plurality offront-end nodes for subsequent distribution to said plurality of callapplication nodes.
 15. The telecommunication network as set forth inclaim 14, wherein a first of said plurality of ALG application groupscomprises a first primary ALG application executed on said first callapplication node and a first backup ALG application associated with saidfirst primary ALG application.
 16. The telecommunication network as setforth in claim 15, wherein said first backup ALG application resides ona call application node other than said first call application node. 17.For use in an Internet Protocol (IP) multimedia subsystem comprising: i)an IP switch and ii) a plurality of call application nodes for executinga plurality of Policy Decision Function (PDF) application groups, amethod of processing Common Open Policy Service (COPS) protocol messagescomprising the steps of: receiving COPS protocol messages from anexternal IP network; and distributing the COPS protocol messages to theplurality of call application nodes according to a load sharingalgorithm.
 18. The method as set forth in claim 17, wherein a first oneof the plurality of PDF application groups is executed on a first one ofthe plurality of call application nodes and is associated with a similarsecond one of the plurality of PDF application groups executed on asecond one of the plurality of call application nodes separate from thefirst call application node.
 19. The method as set forth in claim 18,wherein the first and second PDF application groups form a firstload-sharing group service application.
 20. The method as set forth inclaim 19, wherein the first PDF application group comprises a firstprimary application executed on the first call application node and afirst backup application associated with the first primary application.